Telegram Group & Telegram Channel
StringConcat - разработка без боли и сожалений
Как я получал оффер от банка В Thoughtworks меня только-только сократили, я написал в LinkedIn, что я бедный и несчастный, ищу работу, и лёг спать. В 11:00 следующего дня в телеграме мне пишет неизвестный: «я не знаю кто ты, но я тебя найду уже 3 человека…
Пока Сережа наслаждается успехом, мы снова возвращаемся к духоте.

Коллеги скинули всё ещё актуальную заметку про предварительный анализ. Не обращайте внимания на название, суть там в другом — перед тем как что-то реализовывать, это стоит описать в доке.
Например:
— какие изменения нужно внести
— какие будут контракты
— как лучше тестировать
— etc

Я сам исповедую примерно такой подход уже в нескольких конторах. Кажется, что это бюрократия и трата времени, но в итоге у всех участников выравнивается понимание конечного результата. Особенно когда такая дока пишется сообща. Тестеры понимают, как тестить, разрабы понимают, как ревьювить и т.д. Метод сильно отличается от классического «вот вам задача в жыре, сами понимайте, что я тут имел ввиду, вы ж умные»

В итоге количество непоняток и переделок снижается в разы, легко организовать трассировку, а разработчики уходят с полным пониманием задачи и повышается точность прогнозирования сроков в сторипоинтах.

Что ещё можно добавить в такую доку?
— контекст: зачем мы вообще это делаем, какую задачу решаем
— модель предметной области на основе Event Storming
— use case и альтернативные сценарии
— макеты в Фигме
— какая документация должна родиться
— какие метрики нужно вывести
— какие алерты настроить
— что поменяется в инфраструктуре
— риски безопасности
— любые другие технические подробности
— ссылки на другие документы

Несколько важных наблюдений

1. Документ обычно описывает ближайшую задачу, никаких «на вырост». Версии тут как таковых нет, потому что мы очень плохо можем в дифф.

2. Документ обычно пишется на пользовательскую историю или похожий артефакт, то есть в изготовлении доки задействуются и фронтендеры и бекендеры и тестировщики, которым это потом чинить. Далее сторя разбивается на подзадачи для конкретных спецов. Фактически мы начинаем разрабатывать на бумаге, продумываем самые сложные сценарии, а кодить можно уже спинным мозгом. В этом отличие от классических требований (даже самых подробных) описываемых аналитиками.

3. Документирование может отмереть, если команда нарастит квалификацию и достаточно сработается. Это нормально, потому что цель — не бумажка, а общее понимание результата.

4. Подход слабо работает в лапшекоде уровня «после просмотра промыть глазаа хлоргексидином», ибо количество непредвиденных ситуаций ломает начальную идею полностью. Хотя полностью от них избавиться не получится даже в поддерживаемом коде



tg-me.com/stringconcat/266
Create:
Last Update:

Пока Сережа наслаждается успехом, мы снова возвращаемся к духоте.

Коллеги скинули всё ещё актуальную заметку про предварительный анализ. Не обращайте внимания на название, суть там в другом — перед тем как что-то реализовывать, это стоит описать в доке.
Например:
— какие изменения нужно внести
— какие будут контракты
— как лучше тестировать
— etc

Я сам исповедую примерно такой подход уже в нескольких конторах. Кажется, что это бюрократия и трата времени, но в итоге у всех участников выравнивается понимание конечного результата. Особенно когда такая дока пишется сообща. Тестеры понимают, как тестить, разрабы понимают, как ревьювить и т.д. Метод сильно отличается от классического «вот вам задача в жыре, сами понимайте, что я тут имел ввиду, вы ж умные»

В итоге количество непоняток и переделок снижается в разы, легко организовать трассировку, а разработчики уходят с полным пониманием задачи и повышается точность прогнозирования сроков в сторипоинтах.

Что ещё можно добавить в такую доку?
— контекст: зачем мы вообще это делаем, какую задачу решаем
— модель предметной области на основе Event Storming
— use case и альтернативные сценарии
— макеты в Фигме
— какая документация должна родиться
— какие метрики нужно вывести
— какие алерты настроить
— что поменяется в инфраструктуре
— риски безопасности
— любые другие технические подробности
— ссылки на другие документы

Несколько важных наблюдений

1. Документ обычно описывает ближайшую задачу, никаких «на вырост». Версии тут как таковых нет, потому что мы очень плохо можем в дифф.

2. Документ обычно пишется на пользовательскую историю или похожий артефакт, то есть в изготовлении доки задействуются и фронтендеры и бекендеры и тестировщики, которым это потом чинить. Далее сторя разбивается на подзадачи для конкретных спецов. Фактически мы начинаем разрабатывать на бумаге, продумываем самые сложные сценарии, а кодить можно уже спинным мозгом. В этом отличие от классических требований (даже самых подробных) описываемых аналитиками.

3. Документирование может отмереть, если команда нарастит квалификацию и достаточно сработается. Это нормально, потому что цель — не бумажка, а общее понимание результата.

4. Подход слабо работает в лапшекоде уровня «после просмотра промыть глазаа хлоргексидином», ибо количество непредвиденных ситуаций ломает начальную идею полностью. Хотя полностью от них избавиться не получится даже в поддерживаемом коде

BY StringConcat - разработка без боли и сожалений




Share with your friend now:
tg-me.com/stringconcat/266

View MORE
Open in Telegram


StringConcat разработка без боли и сожалений Telegram | DID YOU KNOW?

Date: |

The Singapore stock market has alternated between positive and negative finishes through the last five trading days since the end of the two-day winning streak in which it had added more than a dozen points or 0.4 percent. The Straits Times Index now sits just above the 3,060-point plateau and it's likely to see a narrow trading range on Monday.

Mr. Durov launched Telegram in late 2013 with his brother, Nikolai, just months before he was pushed out of VK, the Russian social-media platform he founded. Mr. Durov pitched his new app—funded with the proceeds from the VK sale—less as a business than as a way for people to send messages while avoiding government surveillance and censorship.

StringConcat разработка без боли и сожалений from de


Telegram StringConcat - разработка без боли и сожалений
FROM USA